Saltar al contenido principal

Grupo 4

En este documento vamos a encontrar el feedback recibido por el grupo 4

Semana 1: 06/02​

  • Reducir el número de personas que exponen, ya que puede suponer una distracción para el público.
  • Detallar el modelo de negocio, medidas de seguridad y verificación de la existencia del piso.
  • Está bien no asociar roles a personas, sino que todo el mundo sea multidisciplinar. Pero en los roles que sí se definan, como el PM, es importante la comunicación entre el anterior y el nuevo, y hay que determinar ciertas medidas para no sobrecargar al nuevo con cosas que no hizo el anterior.
  • Trabajar en la seguridad ante bots. Para ello, se puede verificar a los usuarios mediante algún método como DNI, foto o similares.
  • Implementar un reloj de equipo para saber cómo se está invirtiendo el tiempo.
  • Describir casos de uso mínimos de una manera más exhaustiva para que la audiencia pueda entender la diferencia entre ellos.
  • Se podría validar la existencia del piso para garantizar la seguridad. Se propone usar el código de catastro o algún similar.

Semana 2: 13/02​

  • Conveniente la definición de políticas de commits y convenciones.
  • Sugerencia de hablar de tecnologías de comunicación y control del tiempo.
  • Falta de información sobre cómo se administrará el uso de inteligencia artificial.
  • Falta un inicio efectivo, al parecer el silencio no es un inicio efectivo.
  • Entregar documento de TCO, ya que se ha elaborado exhaustivamente.
  • Identificar cliente, en nuestro caso podría ser el usuario.
  • Mejorar el análisis de competidores. Explicar por qué se excluyen competidores, usar herramientas para buscar competidores, buscar keywords,...
  • Replantear pricing sobre lo que nos diferencia del resto (Realmente se ha explicado mal lo que nos diferencia del resto, que son los chats grupales)
  • Desarrollar la idea de usar etiquetas de usuario.
  • No pasar diapositivas dando por hecho que ya está explicado.
  • Resumir texto de los planes de contingencia de riesgos.
  • Hacer seguimiento de riesgos en cada iteración.
  • Si el riesgo es muy probable, hay que actuar antes de que ocurra, no solo cuando ocurra.
  • Hacer seguimiento de que se siga el commitment agreement.
  • Indicar transparencias en los que se ha aplicado el feedback anterior con un icono.
  • Los mocks al final mejoran la fluidez puesto que no cortan la presentación.
  • No queda claro la geolocalización por rango.
  • Disonancia entre algunas imágenes y lo explicado.
  • No separar los costes de producción del TCO, puesto que dichos costes son parte de él.
  • Sintetizar la información del TCO.

Semana 3: 20/02​

  • Mejorar el inicio efectivo.
  • Hacer uso del micrófono si es necesario.
  • Desglosar el TCO.
  • A la hora de mostrar el pricing, primero mostrar todos los planes y luego detallar cada uno.
  • Falta la Landing Page.
  • Añadir estadísticas sobre IA y desarrollo (cantidad de pull requests, si se ha usado mucho o no la IA).
  • Buscar usuarios piloto como estudiantes que buscan piso.
  • Cambiar los mockups para que contengan imágenes mas realistas.

Semana 4: 27/02​

  • Resumen monótono en la presentación
  • Para el versionado de documentos se crea una carpeta de documentos y al final de cada semana se saca el pdf con un número de versión actualizado.
  • Falta el elevator pitch.
  • Leer las diapositivas si son largas para mantener la atención del público.
  • Más apoyo visual para el elevator pitch.
  • Especificar qué es la categoría "otros" en los usuarios piloto o eliminarla.
  • Trazar planificación sobre cómo tratar a los usuarios piloto.
  • Hablar de porcentajes cuando se hable de usuarios al mes.
  • Especificar cómo escala el tco y los beneficios con más usuarios.
  • Añadir estadísticas del INE.
  • Para regular el CA, si en una semana no se llega al 80, en la siguiente se hace un 120.
  • El rendimiento debe ser relativo al número de horas que se deben dedicar.
  • Definir a qué nota aspira cada miembro del grupo y especificarlo en el CA.
  • Especificar qué tareas hace cada subgrupo, con un pseudodiagrama de Gantt.
  • Para la retrospectiva, en vez de poner un tablero, poner un resumen.
  • Los problemas deben tener una propuesta de mejora, objetivo de mejora y la medición de cómo de efectiva es.
  • En la última columna de análisis de rendimiento, indicar con unas flechas verdes o rojas si el rendimiento está mejorando o empeorando.
  • Considerar ventajas y desventajas de una demo en directo o grabada.
  • Dividir sprints 2 y 3 en diapositivas aparte para evitar confusión sobre qué se hacce en cada uno.
  • Evitar hablar mal de los competidores y añadir más.

Semana 5: 05/03​

  • Falta el estado de los usuarios piloto.
  • Poner el número de las diapositivas alto para que se vea mejor desde atrás.
  • Orden de "Uso de las IAs" y "Usuarios piloto" incorrectos.
  • Poner fotos de apoyo en el killer opener.
  • Grabar presentación está bien, pero hacer más zoom.
  • No perder tiempo rellenando formularios, precargarlos.
  • No usar la misma fórmula de rendimiento para todos los roles.
  • Las tareas de coordinación no se miden como puntos de historia.
  • Añadir login social.
  • La matriz RACI debe corresponder con el github.
  • Ver como medir las acciones de mejora para los problemas.

Semana 6: 12/03 (Retrospectiva)​

  • Ajustar la linea ideal a lo real, no aplicarnos fines de semana/fiesta y usar nuestro calendario de horas
  • Usar una épica/milestone que reuna las issues de refactorización
  • Separar la nota de desarrollo y coordinación y medir el grado de satisfacción del grupo con respecto al GM. (Para que el bajo rendimiento de un miembro del grupo no le afecte).
  • Usar gráfica de control chart para ver la diferencia entre tareas que se entregan antes y más tarde, buscar que el control chart llegue lo más cercano a la media para mostrar la equidad entre las tareas.
  • Poner issues de control de calidad para saber si la planificación está bien definida
  • Realizar acuerdo con grupo de usuarios piloto para asegurar que ambas partes cumplen el trabajo en el tiempo que se requiere.
  • Mostrar perfiles de github y clockify.
  • Ver puntuaciones proporcionadas y tareas asignadas a cada individuo.

Semana 7: 19/03​

  • Comprobar el volumen antes de la presentación para evitar problemas.
  • No confundir Commitment Agreement con Customer Agreement.
  • Facilitar un enlace para el GDPR Y terminos de uso.
  • Poner datos realistas en la demo.
  • Hacer mayor énfasis en diferencias con los competidores.
  • Indicar estado de los problemas y métricas para medir si se están solucionando.
  • Justificar el recorte en el alcance.
  • Mejorar elevator pitch.

Semana 8: 02/04​

  • Incluir datos reales reales en demos.
  • No confundir terminos (Beneficios =! ingresos).
  • Añadir alucinaciones al uso de la IA.
  • Hacer zoom en las partes que se vea poco.
  • Seguir el orden que indiquen los profesores.
  • Bajar el ritmo de la presentación en partes como los diagramas.
  • Cambiar colores y escala de gráfica coste vs beneficio para que se vea mejor.
  • Poner reloj del equipo en la retrospectiva.
  • Añadir mediciones a las soluciones en la tabla de problemas.

Semana 9: 09/04​

  • Se ha ido muy rápido en la parte de los riesgos aunque estaban bien estructurados y presentados visualmente.
  • Poner desglose de horas por miembro de todo el mundo en una misma diapositiva.
  • Usuarios piloto bien: identificación de usuarios piloto bien y cantidad, fechas de inicio-fin de prueba (falta cuándo se analiza y aplica el feedback), calificación (falta prioridad del feedback).
  • En planificación ha faltado cómo vamos a gestionar el final del S3 - WPL (Tareas faltantes, replanificar si hiciera falta).

Semana 10: 23/04​

  • La historia de la demo debería ser general y orientada a un usuario nuevo. Orientarla a toda la funcionalidad y no solo al S3.
  • En el elevator pitch incluir roles e historia.
  • Evitar poner demasiado texto para que no parezca que se leen diapositivas en vez de presentarlas.
  • Para cada problema o mejora hay que tener claro acciones concretas, medida para evaluar sí está funcionando, un umbral y un tiempo objetivo.
  • En la pirámide de UX, desarrollar los comentarios de los usuarios piloto para justificar.
  • Hacer que la demo esté hilada con una historia, es más interesante.

Semana 11: 30/04​

  • Revisar modelo de negocio.
  • La demo es una que alguien ve por primera vez y que muestra sólo lo más importantes.
  • Orientar la presentación al usuario y al mismo tiempo al inversor.
  • Evitar usar demasiados tecnicismos.
  • Responder a preguntas ¿por qué voy a invertir, cuánto y cuándo vas a ganar.
  • Agrupar y resumir más los costes.

Semana 12: 07/05​

  • Mejorar la fluidez del inicio y de la transicion entre diapositivas.
  • No decir roles, hay que transmitir que es un equipo multidisciplinar.
  • No detallar demasiado los costes.
  • Reducir las formulas, explicar en que nos basamos y numeros finales en el anuncio de inversores.
  • Poner temporalidad en el plan de precios.
  • Poner en el orden optimista-realista-pesimista. Poner los valores encima de cada estimación.
  • Comentar sólo el caso realista en el anuncio.
  • Si en el vídeo se han puesto cosas, no hace falta que se ponga en las transparencias.